fix(progress-spinner)!: errors following a full review of the component (#DS-5482) - #1979

`size` was the last accessor input on the spinner, and the reason the automated
signal migration skipped it: its setter stored the size and computed the SVG
circle radius in one go. The radius is a `computed` now and `size` is a plain
`input()`, typed `ProgressSpinnerSize` instead of an arbitrary string — which
resolves a TODO that predates this review.

`value` gained `numberAttribute`: `value="40"` used to pass the string `"40"`,
which the percentage arithmetic coerced by accident.

`percentage`, `dashOffsetPercent` and `svgCircleRadius` are `protected`. They are
derived from the inputs the consumer already binds, and the last one is SVG
geometry rather than a contract.

The generated `id` comes from the CDK `_IdGenerator` instead of a module-level
counter, so it no longer collides across lazily loaded bundles.

`KbqLoaderOverlay.spinnerSize` reports `ProgressSpinnerSize` rather than `string`
to keep feeding the narrowed input.

BREAKING CHANGE: `KbqProgressSpinner.size` is a signal and no longer accepts an
arbitrary string; `percentage`, `dashOffsetPercent` and `svgCircleRadius` are
protected; `value` is a `numberAttribute` input, so a `null` binding yields `NaN`
where it used to clamp to `0`. Reported and partly rewritten by the
`progress-spinner-signals` schematic.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

`numberAttribute` with no fallback turned a null binding into `NaN`, and the
value feeds a `stroke-dashoffset` percentage — `NaN%` is not a CSS length, so
the browser dropped the declaration and the circle rendered full. It falls back
to 0, which is what the pre-migration input did.

The schematic counted a `.html` file as a consumer only when it had a `size` read
to rewrite, so a template-only consumer never heard that `size` no longer accepts
an arbitrary string.

Tests: the uniqueness assertion compared a generated id against a bound one, so
it passed without testing uniqueness; and nothing covered `value="40"` as a
static attribute, which is the case the transform exists for.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

20.3.0 was released on main, so #2005 moved every staged migration to 21.0.0-0.
Two things the merge needed beyond the automatic resolution:

- progress-spinner-signals merged in still registered for 20.3.0-0, which git had
  no reason to touch because the entry is an addition. At that version the
  migration would never run for anyone upgrading to 21, so it joins the other 28
  on 21.0.0-0, together with the version in its README and its data.ts docblock.
- loader-overlay.api.md conflicted: this branch narrowed `spinnerSize` to
  `ProgressSpinnerSize` while main added the `surface` input. The file is
  generated, so it was regenerated with `approve-api` rather than merged by hand;
  the result carries both.

The markdown review (#1981) landed on main, so only its two registry entries
conflicted, at the append point every review branch shares: kept main's entries
and appended progress-spinner-signals after them.

Both guides auto-merged correctly this time - main's block already ends with
Popover and the Markdown subsection it added sorts before Progress spinner, so
the alphabetical order came out right without help. The migration is already
registered for 21.0.0-0 from the previous merge, so nothing to re-version.